home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / internet-drafts / draft-ietf-x400ops-dnsx400rout-01.txt < prev    next >
Text File  |  1993-03-03  |  47KB  |  1,180 lines
  1.  
  2. Network Working Group                                      February 1993
  3. Internet-DRAFT v4.1
  4.  
  5.  
  6.  
  7.    Using the Internet DNS to maintain X.400 MHS Routing Informations
  8.  
  9.  
  10.  
  11.              Claudio Allocchio (Allocchio@elettra.trieste.it)
  12.                Antonio Blasco Bonito (bonito@cnuce.cnr.it)
  13.                        Bruce Cole (bcole@cisco.com)
  14.                     Silvia Giordano (giordano@cscs.ch)
  15.                       Robert Hagens (hagens@ans.net)
  16.  
  17.                                GARR-Italy
  18.                            Cisco Systems Inc.
  19.                   Centro Svizzero Calcolo Scientifico
  20.                       Advanced Network & Services
  21.  
  22.  
  23. 0. Status of this memo
  24.  
  25.    This memo proposes a method of storing in the Internet Domain Name 
  26.    System the routing information needed by X.400 MTAs within an X.400 
  27.    MHS. Routing information can be managed in a distributed rather than 
  28.    a centralized way. MTAs located on Internet hosts can retrieve the 
  29.    routing information querying the DNS instead of having fixed tables 
  30.    which need to be centrally updated and distributed. This document 
  31.    specifies a prototype standard proposal. This memo is a joint effort
  32.    of X400 operation working group and RARE Mail and Messaging working
  33.    group.
  34.  
  35.    Distribution of this memo is unlimited.
  36.  
  37.    Another document by the same authors describes a method to store and 
  38.    distribute the RFC1327 mapping information using the Internet DNS.
  39.  
  40.    This document is an Internet Draft. Internet Drafts are working 
  41.    documents of the Internet Engineering Task Force (IETF), its Areas, 
  42.    and its Working Groups. Note that other groups may also distribute 
  43.    working documents as Internet Drafts. 
  44.  
  45.    Internet Drafts are draft documents valid for a maximum of six 
  46.    months. Internet Drafts may be updated, replaced, or obsoleted 
  47.    by other documents at any time. It is not appropriate to use 
  48.    Internet Drafts as reference material or to cite them other than 
  49.    as a "working draft" or "work in progress."
  50.  
  51.    Please check the I-D abstract listing contained in each Internet 
  52.    Draft directory to learn the current status of this or any other 
  53.    Internet Draft.
  54.  
  55.  
  56.  
  57.  
  58. Allocchio et. al.      (Doc. expiration date:  June 1993)       [Page 1]
  59.  
  60. I-d v4.1      Internet DNS for X.400 MHS routing data      February 1993
  61.  
  62.  
  63. 1. Introduction
  64.  
  65.    The routing informations are an essential element to implement an 
  66.    efficient e-mail service within any community. In the Internet Domain 
  67.    Name System the "A" and "MX" records are used to store and distribute 
  68.    dynamically the routing information used by mailers to transport and 
  69.    deliver e-mail messages. In X.400 MHS usually static tables contain 
  70.    the routing data.
  71.  
  72.    In the early X.400 times, the MHS configurations were quite simple: 
  73.    a few well managed MTAs (often called "Well known Entry Point" or 
  74.    "WEP") were taking care of the whole routing for one or more 
  75.    communities; all the traffic was managed by static point-to-point 
  76.    connections among the WEPs, and often there was only one network 
  77.    transport available (usually X.25 or TCP with RFC1006). In this 
  78.    situation static tables proved to be enough to run such initial 
  79.    service.
  80.  
  81.    The rapid growth of X.400 Message Handling Systems, however, made
  82.    very soon inadequate the use of a simple statically defined database:
  83.    in fact the X.400 addresses tree grows daily adding new branches and 
  84.    many new MTAs show up either. More over a large number of X.400 
  85.    implementations now support multiple transport stacks, allowing a 
  86.    real and global connectivity.
  87.  
  88.    Many efforts have been done in order to take in account this new 
  89.    situation, and a document defining the X.400 MHS routing strategy has 
  90.    been defined by Urs Eppenberger from SWITCH/COSINE MHS project team 
  91.    [EPPEN V3]. In that document the approach to the routing problem is 
  92.    again table driven, using the so called "DOMAIN" and "RELAY" tables 
  93.    (section 4). Two additional tables, "COMMUNITY" and "PERSON", 
  94.    complete the data about the X.400 MHS. That document, however, has 
  95.    been carefully designed to allow easily the store of the information
  96.    it defines in distributed databases like DNS or X.500: our aim is to
  97.    define the use of DNS to store those routing information.
  98.  
  99.    A first proposal to use the Internet DNS to store, to retrieve and to 
  100.    maintain X.400 related information (the RFC1327 mapping tables) was 
  101.    introduced by two of the authors (B. Cole and R. Hagens). However it 
  102.    required modifications to the actual Internet DNS nameservers and, 
  103.    due to the large variety of currently available implementations, this 
  104.    was unfeasible within a reasonable time.
  105.  
  106.    A different approach, using already defined, commonly available DNS 
  107.    resource-record types to store the information is proposed now. In 
  108.    addition, the use of a new domain name space is envisaged in order to 
  109.    fully implement a distributed X.400 routing information tree: again 
  110.    the MX resource-records will be used, jointly with some other ones 
  111.    needed to store the more complex X.400 routing data.
  112.  
  113.    The creation of the new domain name space also provides the chance to 
  114.    use the DNS to distribute dynamically the X.400 to/from RFC822 
  115.  
  116.  
  117. Allocchio et. al.      (Doc. expiration date:  June 1993)       [Page 2]
  118.  
  119. I-d v4.1      Internet DNS for X.400 MHS routing data      February 1993
  120.  
  121.  
  122.    mapping information described in RFC1327, thus solving another 
  123.    efficiency problems currently affecting the X.400 MHS
  124.    implementations. 
  125.  
  126.    In this paper we will adopt the DOMAIN and RELAY document definitions 
  127.    from [EPPEN V3] routing coordination document.
  128.  
  129. 1.1 Definitions syntax
  130.  
  131.    The definitions in this document is given in BNF-like syntax, using 
  132.    the following conventions:
  133.  
  134.      |     means choice
  135.      \     is used for continuation of a definition over several lines
  136.      []    means optional
  137.      {}    means repeated one or more times
  138.  
  139.    The definitions, however, are detailed only until a certain level, 
  140.    and below it self-explaining character text strings will be used.
  141.  
  142. 2.  Motivation
  143.  
  144.    The implementation of a fully meshed connectivity among MTAs, and the 
  145.    ability to use at best the available network transport stacks require 
  146.    to disseminate complete and up to date routing data to all MTAs. In  
  147.    the Internet community, the DNS has proven to be a practical mean for 
  148.    providing a distributed name service. Advantages of using a DNS based 
  149.    system over a table based approach for mapping between O/R  addresses  
  150.    and domain names are:
  151.  
  152.      - It avoids fetching and storing of entire routing tables by every 
  153.        MTA wishing to use full connectivity.
  154.  
  155.      - Modifications to the DNS based routing information can be made  
  156.        available in a more timely manner than with a table driven 
  157.        approach.
  158.  
  159.      - Table management is not necessarily required for DNS-based X.400 
  160.        MTAs.
  161.  
  162.      - One can determine the routing in use by a remote MTA by querying 
  163.        the DNS (remote debugging).
  164.  
  165.    Routing decisions taken by the MTAs involved in delivering an X.400 
  166.    message will also be more likely to result correct, if the routing 
  167.    information is updated in real time.
  168.  
  169. 3. Proposal: the new "X400.ARPA" domain space
  170.  
  171.    Usual domain names (the ones normally used as the global part of an 
  172.    RFC822 e-mail address) and their associated information, i.e. host IP 
  173.    addresses, mail exchanger names, etc., are stored in the DNS as a 
  174.  
  175.  
  176. Allocchio et. al.      (Doc. expiration date:  June 1993)       [Page 3]
  177.  
  178. I-d v4.1      Internet DNS for X.400 MHS routing data      February 1993
  179.  
  180.  
  181.    distributed database under a number of top-level domains (EDU, COM, 
  182.    countries like UK, IT, FR, etc.). The special top-level/second-level 
  183.    couple IN-ADDR.ARPA is used to store the IP address to domain name 
  184.    relationship.
  185.  
  186.    Our proposal, which closely resembles the above model, is to store 
  187.    the X.400 routing data in a new branch of the DNS name space (under 
  188.    the already defined top-level domain "ARPA") using the MX and HINFO 
  189.    resource records. In particular in this new name space "X400.ARPA" 
  190.    we will have a complete set of existing resource records available 
  191.    to store any other useful information concerning X.400, like 
  192.    RFC1327 mappings, responsible people, etc.
  193.  
  194.    This name space is thus used to contain completely the information: 
  195.    the data required by an MTA to route an X.400 message to destination 
  196.    can be easily found with a simple query to the nearest nameserver. 
  197.    Moreover there is no more any need to store, maintain and distribute 
  198.    manually those tables.
  199.  
  200.    The special name space begins at the top-level "X400.ARPA" and should 
  201.    have a structure following the X.400 hierachical structure (country, 
  202.    ADMD, PRMD, organisation, ...). The fully qualified MX and HINFO 
  203.    resource-records are constructed starting from the information 
  204.    contained in the DOMAIN and RELAY documents.
  205.  
  206.    The construction of the new domain space tree will follow the same 
  207.    procedures used when organising at first the already existing DNS 
  208.    space: authoritative information about the X400.ARPA top-level domain 
  209.    is maintained by the root servers while a central nameserver in each 
  210.    country is delegated by the root servers to hold the national part of 
  211.    the routing tables. At first, however, the information will be 
  212.    stored in a quite centralised way, and distribution of authority will
  213.    be gradually achieved. A separate document will describe the 
  214.    implementation phase.
  215.  
  216. 4. Storing X.400 routing information
  217.  
  218.    In the usual domain name space the MX records are used to store 
  219.    information for SMTP mailers; their content is a list of possible 
  220.    Mail eXchanger and a pure number stating the preferred order of these
  221.    mailers (priority). The creation of a new domain space under 
  222.    X400.ARPA top level domain, enables now us to use the MX resource 
  223.    records in it to store information about routing in the X.400 MHS,
  224.    using the same principles adopted by SMTP mailers. Some other DNS 
  225.    resource records will then be used to store the additional data 
  226.    present in the RELAY and DOMAIN documents described in sect. 5.3 and
  227.    5.4 of [EPPEN V3] document.
  228.  
  229.    The syntax form of the usual MX record in DNS is:
  230.  
  231.       <domain>  <class>  MX  <prio>  <dest-host-domain>
  232.  
  233.  
  234.  
  235. Allocchio et. al.      (Doc. expiration date:  June 1993)       [Page 4]
  236.  
  237. I-d v4.1      Internet DNS for X.400 MHS routing data      February 1993
  238.  
  239.  
  240.    where <dest-host-domain> is then resolved via an "A" resource record 
  241.    into an IP host address: in fact the only transport foreseen in DNS 
  242.    for SMTP protocol is TCP/IP, and the socket number 25 is already 
  243.    reserved. Also  NJE, DDCMP and X.25 transports  are used for SMTP 
  244.    (BSMTP, DSMTP and XSMTP), but their connection data are not included 
  245.    and distributed via DNS.
  246.  
  247.    In the X.400 MHS routing document we can identify these elements:
  248.  
  249.       <OR-matching><MHS-subtree>  <RELAY-Priority>  <UniqueRELAYkey>
  250.  
  251.    which can be somehow equivalenced to the usual DNS elements. However 
  252.    the routing can be done on different protocol stacks, and each stack 
  253.    can have a different priority. Thus we have additional data for each 
  254.    specific stack like <Service-type>, <P-address>, <Service-priority>, 
  255.    <MTS>.
  256.  
  257.    On the other hand, the MTA connection data are much more complex 
  258.    than a simple 4-byte IP address. We have in fact <RTS>, <password>, 
  259.    <called-connection>, <calling connection>, etc. and many of these 
  260.    elements are themselves a set of complex data. Thus we will need 
  261.    additional resource records to store these data.
  262.  
  263. 4.1 Detailed storage proposal for routing information in DNS
  264.  
  265.    To implement in the most convenient way the storage of X.400 MHS 
  266.    routing data we can take advantage of the DNS MX records; in fact 
  267.    they already provide wildcard support and a priority mechanism.
  268.    Other available DNS resource record types will be then used for the 
  269.    remaining RELAY data; in particular the HINFO resource record can be 
  270.    used for the RELAY connection and system data.
  271.  
  272.    Let us define the <MHS-route-record> object which can be inserted 
  273.    into a DNS MX resource record:
  274.  
  275.      <MHS-route-record> ::= <MHS-ORdomain> "IN" "MX" <RELAY-priority> \
  276.                             <RELAY-data>
  277.  
  278.    where:
  279.  
  280.      <MHS-ORdomain> ::= DNS translation of <OR-matching><MHS-subtree>
  281.                         (sect. 4.3.1)
  282.  
  283.      <RELAY-priority> ::= <Number 0..99>  (see [EPPEN V3] sect. 5.4)
  284.  
  285.      <RELAY-data> ::= { <DNS-Service-key> ["-" <DNS-Priority>] "." } \
  286.                         <DNS-RELAYkey>
  287.  
  288.      <DNS-Service-key> ::= A unique keyword to identify a 
  289.                            <RELAY-call-data> and <RELAY-clng-data>
  290.                            record (sect. 4.3.5)
  291.  
  292.  
  293.  
  294. Allocchio et. al.      (Doc. expiration date:  June 1993)       [Page 5]
  295.  
  296. I-d v4.1      Internet DNS for X.400 MHS routing data      February 1993
  297.  
  298.  
  299.      <DNS-Priority> ::= DNS translation of <Service-priority> 
  300.                         (sect. 4.3.4)
  301.  
  302.      <DNS-RELAYkey> ::= DNS translation of 
  303.                         <UniqueRELAYkey><local-domain> (sect. 4.3.2)
  304.  
  305.    The presence of <OR-matching> element in the DOMAIN document 
  306.    determines the distinction between wildcard and exact matching of an 
  307.    O/R address with <MHS-subtree>: in DNS this will be implemented with 
  308.    the provided MX wildcard mechanism (see an example in section 4.3.1).
  309.  
  310.    The <DNS-RELAYkey>, as you can see, is the translation of the 
  311.    combination of <UniqueREALYkey> and <local-domain>; this requires the 
  312.    mandatory presence of the <local-domain> information, even if this 
  313.    information is defined as optional in [EPPEN V3]. The <DNS-RELAYkey> 
  314.    must in fact be located in the correct branch of the X400.ARPA DNS 
  315.    tree, i.e. exactly where the authority managing the RELAY lies. A 
  316.    similar situation occurs also for the location of the MTA object  
  317.    within the X.500 tree. As a consequence, for a community wishing to 
  318.    distribute its routing information via DNS, the <local-domain> 
  319.    element becomes mandatory.
  320.  
  321.    The additional data for a RELAY connection are stored into HINFO DNS 
  322.    resource records. In particular we need to store information about 
  323.    the RELAY itself (<status>, <password>, <RTS>, <system>) and about 
  324.    the network connectivity (<service-type>, <MTS> and <P-address>). 
  325.    We define thus three records, which will be stored into three 
  326.    different DNS HINFO records:
  327.  
  328.    <RELAY-host-data> ::= <DNS-RELAYkey>  "IN" "HINFO" \
  329.                        "<status> <password> <DNS-RTS> [<system>]" \
  330.                        "<DNS-Service-key> { [ "." <DNS-Service-key> ] }"
  331.  
  332.    <RELAY-call-data> ::= "C."<DNS-Service-key>"."<DNS-RELAYkey> \
  333.                          "IN" "HINFO" "<password> <DNS-RTS> <MTS>" \
  334.                           "<P-address>"
  335.  
  336.    <RELAY-clng-data> ::= "R."<DNS-Service-key>"."<DNS-RELAYkey> "IN" \
  337.                          "HINFO" "<password> <DNS-RTS>" "<P-address>"
  338.  
  339.    where:
  340.  
  341.      <DNS-RTS> ::= DNS translation of <RTS> (sect. 4.3.3)
  342.  
  343.    and <status>, <password>, <system>, <MTS>, <P-address> are defined in 
  344.    [EPPEN V3], sect. 5.1 and 5.3.
  345.  
  346.    Note that the <DNS-Service-key> list contained into the 
  347.    <RELAY-host-data> record must contain exactly the same elements used 
  348.    for any couple of <RELAY-call-data> and <RELAY-clng-data> records, 
  349.    i.e. is we have 3 couples of connection information records using 
  350.    "XX0", "RX0" and "IT6" keys, then this list must be present in the 
  351.    <RELAY-host-data> record.
  352.  
  353. Allocchio et. al.      (Doc. expiration date:  June 1993)       [Page 6]
  354.  
  355. I-d v4.1      Internet DNS for X.400 MHS routing data      February 1993
  356.  
  357.  
  358.    The HINFO resource record can hold up to twice 256 octet strings, 
  359.    allowing thus enough available space even for complex <P-address> 
  360.    data.
  361.  
  362.    We can understand better the reason of the three HINFO resource 
  363.    records defined previously if we think of the multiple stacks 
  364.    available for an X.400 MHS: an MTA has some data which are 
  365.    independent from the network stack being used (stored into 
  366.    <RELAY-host-data>) and on the contrary some other information 
  367.    depending upon it (stored into <RELAY-call-data> and 
  368.    <RELAY-clng-data>).
  369.  
  370. 4.2 Basic mappings
  371.  
  372.    The formal definition of an MX resource record is (RFC1035, sect. 
  373.    3.3.9):
  374.  
  375.            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  376.            |                  PREFERENCE                   |
  377.            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  378.            /                   EXCHANGE                    /
  379.            /                                               /
  380.            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  381.  
  382.    where:
  383.  
  384.    PREFERENCE   A 16 bit integer which specifies the preference given 
  385.                 to this RR among others at the same "owner name". 
  386.  
  387.    EXCHANGE     A <domain-name> which specifies a host willing to act 
  388.                 as a mail exchange for the "owner name".
  389.  
  390.    and also the "owner name" is a <domain-name> element. 
  391.  
  392.    At the same time the formal definition of an HINFO resource record 
  393.    is (RFC1035, sect. 3.3.2)
  394.  
  395.            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  396.            /                      CPU                      /
  397.            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  398.            /                       OS                      /
  399.            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  400.  
  401.    where:
  402.  
  403.    CPU and OS area both of <character-string> type and the "owner name" 
  404.    is a <domain-name> element.
  405.  
  406.    In our proposal, <MHS-ORdomain>, <RELAY-data>, <RELAY-host-data>, 
  407.    <RELAY-call-data> and <RELAY-clng-data> must thus be conformant with 
  408.  
  409.  
  410.  
  411.  
  412. Allocchio et. al.      (Doc. expiration date:  June 1993)       [Page 7]
  413.  
  414. I-d v4.1      Internet DNS for X.400 MHS routing data      February 1993
  415.  
  416.  
  417.    the <domain-name> syntax rules, i.e.
  418.  
  419.      <domain-name> ::= <subdomain> | " " 
  420.      <subdomain> ::= <label> | <label>.<subdomain>
  421.      <label> ::= <alphanum> {<alphanumhyphen>} <alphanum>
  422.      <alphanum> ::= "0".."9" | "A".."Z" | "a".."z"
  423.      <alphanumhyphen> ::= "0".."9" | "A".."Z" | "a".."z" | "-"
  424.  
  425.    The definition of <character-string> is simpler: a contiguous set
  426.    of characters without interior spaces, or a 'quoted string', i.e. 
  427.    beginning and ending with " (double quotes). Inside a quoted 
  428.    string any character can occur, except for a " itself, which must
  429.    be quoted using \ (backslash).
  430.  
  431.    As you will notice, the legal character set for <label> does not 
  432.    correspond to the IA5 Printablestring one which is used in 
  433.    <MHS-subtree>; even worse for <uniqueRELAYkey> which can use any 
  434.    ASCII character from (032) up to (126) decimal. However a very 
  435.    simple "escape mechanism" can be applied in order to bypass the 
  436.    problem.
  437.  
  438. 4.3 IA5 Printablestring and ASCII to <alphanumhyphen> mappings
  439.  
  440.    The problem of unmatching character set definition is solved by a 
  441.    simple character mapping rule: whenever a character does not belong 
  442.    to <alphanumhyphen>, then it is mapped using its 3 digit decimal 
  443.    ASCII code, enclosed in hyphens. A small set of special rules is 
  444.    also defined for the most frequent cases. Moreover some frequent 
  445.    characters combinations are also mapped as special cases.
  446.  
  447.    In <MHS-subtree> and <uniqueREALYkey> we can identify a common 
  448.    structure: a sequence of <addr-element>
  449.  
  450.      <addr-element> ::= <attr-label> "=" <attr-value>
  451.      <attr-label> ::= "C" | "A" | "P" | "O" | \
  452.                       "OU1" | "OU2" | "OU3" | "OU4" | \
  453.                       "MTAname"
  454.      <attr-value> ::= IA5-Printablestring | ASCII(032)..ASCII(127)
  455.  
  456.    The label values differ from those defined in RFC1327 for the mapping 
  457.    rules. However both the mapping and routing rules share the same 
  458.    X400.ARPA name space, and thus the sub-trees must have consistent and 
  459.    coherent definitions. For this reason in the following table we also 
  460.    define the appropriate equivalencies.
  461.  
  462.  
  463.  
  464.  
  465.  
  466.  
  467.  
  468.  
  469.  
  470.  
  471. Allocchio et. al.      (Doc. expiration date:  June 1993)       [Page 8]
  472.  
  473. I-d v4.1      Internet DNS for X.400 MHS routing data      February 1993
  474.  
  475.  
  476.    Let's then define the following simple rules:
  477.  
  478.    Original syntax               DNS translation   conditions
  479.    --------------------------------------------------------------------
  480.    missing <attr-label>          <attr-label>      missing seq. element
  481.    <attr-label>"="<blank>        <attr-label>"b"   blank attribute
  482.    "C="                          "C-"              country code
  483.    "A="                          "ADMD-"           administration domain
  484.    "P="                          "PRMD-"           private domain
  485.    "O="                          "O-"              organization
  486.    "OU1=" "OU2=" "OU3=" "OU4="   "OU-"             organization unit
  487.    "MTAname="                    "MTA-"            MTA name
  488.  
  489.    Non <alphanumhyphen> characters in <attr-value>:
  490.  
  491.    Original character      DNS translation      conditions
  492.    --------------------------------------------------------------------
  493.    -                       -h-                  hyphen
  494.    .                       -d-                  quoted dot
  495.    <blank>                 -b-                  blank
  496.    non A/N character       -<3digit-decimal>-   elsewhere
  497.  
  498.    If the DNS store translation of <attr-value> happens to end with an 
  499.    hyphen, then this last hyphen is omitted.
  500.  
  501.    Let's now have some examples:
  502.  
  503.    Original syntax   DNS store translation   condition
  504.    ------------------------------------------------------------------
  505.    missing PRMD      PRMD                    missing attribute
  506.    A=<blank>         ADMDb                   blank attribute
  507.    A=400-net         ADMD-400-h-net          hyphen mapping
  508.    P=UB.AC           PRMD-UB-d-AC            quoted dot mapping
  509.    O=ACME Inc.       O-ACME-b-Inc-d          blank & final hyphen
  510.    P=main-400-a      PRMD-main-h-400-h-a     hyphen mapping
  511.    O=-123-b          O--h-123-h-b            hyphen mapping
  512.    OU1=123-x         OU-123-h-x              hyphen mapping
  513.  
  514.    More complete examples are shown in sect 4.3.1 and 4.3.2
  515.  
  516.    In order to achieve the proper DNS store translations of the X.400 
  517.    routing data some software tools will be used. It is in fact evident 
  518.    that the above conversion rules are not user friendly enough to think 
  519.    of a human made conversion. 
  520.  
  521.    In the next paragraphs we will show for each translation a "step by 
  522.    step" procedure which can be interpreted as a small flow chart to 
  523.    help in designing the tools. The fundamental rule to be applied 
  524.    during translation is, however, the following:
  525.  
  526.    "A string must be parsed from left to right, moving appropriately the 
  527.    pointer in order not to consider again the already translated left 
  528.    section of the string in subsequent analysis."
  529.  
  530. Allocchio et. al.      (Doc. expiration date:  June 1993)       [Page 9]
  531.  
  532. I-d v4.1      Internet DNS for X.400 MHS routing data      February 1993
  533.  
  534.  
  535. 4.3.1 DNS translation of <OR-matching><MHS-subtree>
  536.  
  537.    The syntax for <MHS-ORdomain> corresponds in DNS to a <domain-name> 
  538.    element, while the <OR-matching> can fit into the wildcard 
  539.    specification preceding the <domain-name>. Thus we will follow the 
  540.    approach described in the previous section for non <alphanumhypehn> 
  541.    elements, and a similar solution for the general translation. 
  542.  
  543.    The definition of <MHS-subtree>  in [EPPEN V3] sect. 5.1 is:
  544.  
  545.    <MHS-subtree> ::= ["O=" 'Organization-name' "; "] \
  546.                          [[[["OU1="'OrganizationalUnit-name'"; "]\
  547.                          "OU2=" 'OrganizationalUnit-name' "; "] \
  548.                          "OU3=" 'OrganizationalUnit-name' "; "] \
  549.                          "OU4=" 'OrganizationalUnit-name' "; "] \
  550.                          ["P=" 'PRMDname' "; "] \
  551.                          "A=" 'ADMDname' "; " \
  552.                          "C=" 'Two Character Country Code ISO-3166' ";"
  553.  
  554.    i.e. a string made up by Attribute Labels ("C", "A", "P", "O", "OU1", 
  555.    "OU2", "OU3", "OU4") plus Attribute-Values and ";" as separators. 
  556.  
  557.    This definition allows in its syntax to skip eventually missing 
  558.    intermediate address elements, instead of substituting them with a 
  559.    standard placeholder ("@") as defined in RFC1327 for mapping rules 
  560.    syntax. The new DNS tree under top level domain "X400.ARPA", however, 
  561.    must be coherent in order to allow a correct distribution of 
  562.    authority and a correct sequence of queries along its branches. Thus
  563.    we will insert again the skipped attributes into our DNS translation
  564.    of <MHS-subtree> and <UniqueRELAYkey>.
  565.  
  566.    An equivalent definition of <MHS-subtree> is:
  567.  
  568.    <MHS-subtree> ::= <addr-element> [ { ";" <addr-element> } ]
  569.    <addr-element> ::= <attr-label> "=" <attr-value>
  570.    <attr-label> ::= "C" | "A" | "P" | "O" | \
  571.                     "OU1" | "OU2" | "OU3" | "OU4"
  572.    <attr-value> ::= IA5-Printablestring
  573.  
  574.    To obtain our <DNS-ORdomain> we will use the above translation tables 
  575.    and use the rules described hereunder, along with a detailed example.
  576.  
  577.    Let us suppose:
  578.  
  579.       <MHS-subtree> = OU1=NYC; OU2=saled dpt.; P=AC-me; A= ; C=it;
  580.       <OR-matching> = "* "
  581.  
  582.    1) insert the missing attribute elements in <MHS-subtree> and reorder
  583.       them as OU4, OU3, OU2, OU1, O, P, A, C:
  584.  
  585.       OU2=saled dpt.; OU1=NYC; O; P=AC-me; A= ; C=it;
  586.  
  587.  
  588.  
  589. Allocchio et. al.      (Doc. expiration date:  June 1993)      [Page 10]
  590.  
  591. I-d v4.1      Internet DNS for X.400 MHS routing data      February 1993
  592.  
  593.  
  594.    2) translate <attr-label> as defined above:
  595.  
  596.       OU=saled dpt.; OU=NYC; O; PRMD=AC-me; ADMD= ; C=it;
  597.  
  598.    3) translate <attr-value> as defined above and convert = into -:
  599.  
  600.       OU-saled-b-dpt-d; OU-NYC; O; PRMD-AC-h-me; ADMDb; C-it;
  601.  
  602.    4) replace ";" separators and eventual remaining blanks into ".":
  603.  
  604.       OU-saled-b-dpt-d.OU-NYC.O.PRMD-AC-h-me.ADMDb.C-it.
  605.  
  606.    5) add the top level domain "X400.ARPA" at the end:
  607.  
  608.       OU-saled-b-dpt-d.OU-NYC.O.PRMD-AC-h-me.ADMDb.C-it.X400.ARPA.
  609.  
  610.    6) if <OR-matching> is "* ", then add "*." in front of the string:
  611.  
  612.       *.OU-saled-b-dpt-d.OU-NYC.O.PRMD-AC-h-me.ADMDb.C-it.X400.ARPA.
  613.  
  614.    The final result is then used in DNS as selector to find the 
  615.    appropriate X.400 routing RELAY on a best match basis, exactly as 
  616.    for the RFC822 domains.
  617.  
  618.    Let's have some other examples:
  619.  
  620.       <MHS-subtree>   =  P=WHY;A=mycom;C=ch;
  621.       <OR-matching>   =  "* "
  622.  
  623.    is translated in <DNS-ORdomain> as
  624.  
  625.       *.PRMD-WHY.ADMD-mycom.C-ch.X400.ARPA.
  626.  
  627.    Another one:
  628.  
  629.       <MHS-subtree>  =  OU1=ACME Inc.;P=UB.AC;A= ;C=GB;
  630.       <OR-matching>  =  "= "
  631.  
  632.    is translated in <DNS-ORdomain> as
  633.  
  634.       OU-ACME-b-Inc-d.O.PRMD-UB-d-AC.ADMDb.C-GB.X400.ARPA.
  635.  
  636. 4.3.2 DNS translation of <UniqueRELAYkey><local-domain>
  637.  
  638.    The character set and syntax allowed for a <DNS-RELAYkey> is again 
  639.    the one corresponding in DNS to a <domain-name> element. Thus we 
  640.    will approach the problem as we did for <MHS-subtree>.
  641.  
  642.    Before looking into the translation algorhytm, we must point out 
  643.    again that the <DNS-RELAYkey> need to be placed into the correct 
  644.    branch of the X400.ARPA tree. <UniqueRELAYkey> contains already some
  645.    keys which could help us in this definition; however they are not 
  646.  
  647.  
  648. Allocchio et. al.      (Doc. expiration date:  June 1993)      [Page 11]
  649.  
  650. I-d v4.1      Internet DNS for X.400 MHS routing data      February 1993
  651.  
  652.  
  653.    detailed enough to assure the correct result. Thus we need to make 
  654.    compulsory the presence of <local-domain> which locates fully and 
  655.    unambiguously the RELAY in the DNS tree.
  656.  
  657.    The <UniqueRELAYkey> and <local-domain> elements are defined in sect. 
  658.    5.1 and 5.3 of [EPPEN V3]: 
  659.  
  660.    <UniqueRELAYkey> ::= (["P=" 'PRMDname' "; "] ["A=" 'ADMDname' "; "] \
  661.                        "C=" 'Two Character Country Code ISO-3166' "; " \
  662.                        "MTAname=" 'MTAname' | <DirectoryName> )
  663.  
  664.    <local-domain> ::= "LocalDomain: " <MHS-subtree>
  665.                       The <MHS-subtree> is local to the RELAY.
  666.  
  667.    Note that <UniqueRELAYkey> can also be a <DirectoryName>; however we 
  668.    need to specify completely the information in DNS, avoiding queries 
  669.    to other directory services like X.500. We will thus use the actual 
  670.    data in place of the <DirectoryName> distinguished object to define 
  671.    our <DNS-RELAYkey>.
  672.  
  673.    To define <DNS-RELAYkey> we will take "MTAname=" 'MTAname' from 
  674.    <UniqueRELAYkey> joining it with <MHS-subtree> from <local-domain>:
  675.  
  676.    "MTAname=" 'MTAname' "; " <MHS-subtree>
  677.  
  678.    Let us see in details the steps to obtain <DNS-RELAYkey>. We suppose:
  679.  
  680.      <UniqueRELAYkey> = P=ninf; A=rdnet; C=it; MTAname=int-gw.ninf.it
  681.      <MHS-subtree>    = OU1=int-gw; P=ninf; A=rdnet; C=it;  
  682.  
  683.    1) add MTAname in front of <MHS-subtree>:
  684.  
  685.       MTAname=int-gw.ninf.it; OU1=int-gw; P=ninf; A=rdnet; C=it; 
  686.  
  687.    2) insert the missing attribute elements in <MHS-subtree>:
  688.  
  689.       MTAname=int-gw.ninf.it; OU1=int-gw; O; P=ninf; A=rdnet; C=it;
  690.  
  691.    3) translate <attr-label> as defined above:
  692.  
  693.       MTA=int-gw.ninf.it; OU=int-gw; O; PRMD=ninf; ADMD=rdnet; C=it; 
  694.  
  695.    4) translate <attr-value> as defined above and convert = into -:
  696.  
  697.       MTA-int-h-gw-d-ninf-d-it; OU-cosine-h-gw; O; PRMD-ninf; \
  698.       ADMD-rdnet; C-it; 
  699.  
  700.    5) replace ";" separators and eventual remaining blanks into ".":
  701.  
  702.       MTA-int-h-gw-d-ninf-d-it.OU-cosine-h-gw.O.PRMD-ninf.ADMD-rdnet.\
  703.       C-it. 
  704.  
  705.  
  706.  
  707. Allocchio et. al.      (Doc. expiration date:  June 1993)      [Page 12]
  708.  
  709. I-d v4.1      Internet DNS for X.400 MHS routing data      February 1993
  710.  
  711.  
  712.    6) add the top level domain "X400.ARPA" at the end:
  713.  
  714.       MTA-int-h-gw-d-ninf-d-it.OU-cosine-h-gw.O.PRMD-ninf.\
  715.       ADMD-rdnet.C-it.X400.ARPA.
  716.  
  717.    This element is then ready to be used into DNS resource records.
  718.  
  719.    Let us have another example:
  720.  
  721.      <UniqueRELAYkey> = P=UB.AC; A= ; C=GB; MTAname=UB.AC.mhs-relay
  722.      <MHS-subtree>    = P=UB.AC; A= ; C=GB;  
  723.  
  724.    is translated in <DNS-RELAYkey> as
  725.  
  726.       MTA-ub-d-ac-d-mhs-h-relay.PRMD-UB-d-AC.ADMDb.C-GB.X400.ARPA.
  727.  
  728. 4.3.3 DNS translation of <RTS>
  729.  
  730.    The definition of <RTS> in [EPPEN V3], sect. 5.3 is
  731.  
  732.       <RTS> ::= <dialogue-mode> [<checkpoint-size> <window-size>]
  733.       
  734.       <dialogue-mode> ::= "RTS-dialog-mode: " ("TWA" | "MONOLOGUE")
  735.       <checkpoint-size> ::= "RTS-checkpoint-size: " 'checkpoint size'
  736.       <window-size> ::= "RTS-window-size: " 'window size'
  737.  
  738.    These data will be stored in DNS into HINFO resource records, and 
  739.    thus there is no limitation to the format or character set to use. 
  740.    However the information stored in DNS are for machine use; 
  741.    therefore we will define <DNS-RTS> as a short encoding of these data.
  742.    In particular:
  743.  
  744.       <DNS-RTS> ::= <k-dialogue> [ <k-checkpoint> <k-window> ]
  745.  
  746.    with:
  747.  
  748.       <k-dialogue> ::= "T" | "M"
  749.       <k-checkpoint> ::= "C" 'checkpoint size'
  750.       <k-window> ::= "W" 'window size'
  751.  
  752.    Some examples:
  753.  
  754.    A connection with dialogue=TWA, checkpoint=19 and window=10 will
  755.    result into TC19W10;
  756.  
  757.    A connection with dialogue=MONOLOGUE, checkpoint=5 and window=20
  758.    will result into MC5W20.
  759.  
  760. 4.3.4 DNS translation of <Service-priority>
  761.  
  762.    As <Service-priority> is a pure number, we need to apply a label to 
  763.    it in order to be conformant with RFC1034 and also to distinguish it
  764.  
  765.  
  766. Allocchio et. al.      (Doc. expiration date:  June 1993)      [Page 13]
  767.  
  768. I-d v4.1      Internet DNS for X.400 MHS routing data      February 1993
  769.  
  770.  
  771.    from the other elements. Thus our definition of <DNS-priority> is
  772.  
  773.      <DNS-priority> ::= "P" <Service-priority>
  774.  
  775.    If <Service-priority> is defined as "5", then its DNS translation 
  776.    will be "P5".
  777.  
  778. 4.3.5 Defining the <DNS-Service-key>
  779.  
  780.    The <DNS-Service-key> is just a label to identify a DNS resource 
  781.    record where the relevant MTA connection data are stored. Thus its 
  782.    only requirement is to be unique within an MTA identified by 
  783.    <DNS-RELAYkey>. However it could be very useful to define some 
  784.    criteria and common abbreviations in order to have short keys and 
  785.    also some "guessable" keys for the most common cases. Our suggestion
  786.    is to adopt a three characters key:
  787.  
  788.      <DNS-Service-key> ::= <k-name> <k-service> <k-protocol>
  789.  
  790.      <k-name> ::= one A/N character identifying the network name,
  791.                   adopting the following abbreviations:
  792.  
  793.                        'X' Public-X.25
  794.                        'I' Internet
  795.                        'R' EMPB-X25
  796.                        'L' Int-CLNS
  797.  
  798.      <k-service> ::= "X" | "O" | "L" | "T"
  799.                      standing respectively for X.25, CONS, CLNS, TCP
  800.  
  801.      <k-protocol> ::= "0" | "2" | "4" | "6"
  802.                       standing respectively for TP0, TP2, TP4, RFC1006
  803.  
  804.  
  805.    Thus "Internet/TCP/RFC1006" will produce a <DNS-Service-key> = IT6, 
  806.    while "EMPB-X25/CONS/TP0" produces <DNS-Service-key> = RO0.
  807.  
  808. 4.4 An example of DNS stored DOMAIN and RELAY documents
  809.  
  810.    As said in the previous sections, the X.400 MHS routing data can be 
  811.    stored in DNS using MX and HINFO reseouce records and the set of 
  812.    defined mapping rules. Let's see an example containing the routing 
  813.    data of a management domain. In particular we will consider a DOMAIN 
  814.    document with 2 RELAYs.
  815.  
  816.  
  817.  
  818.  
  819.  
  820.  
  821.  
  822.  
  823.  
  824.  
  825. Allocchio et. al.      (Doc. expiration date:  June 1993)      [Page 14]
  826.  
  827. I-d v4.1      Internet DNS for X.400 MHS routing data      February 1993
  828.  
  829.   
  830.    DOMAIN document (part):
  831.  
  832.      Community: MY-MHS
  833.      #
  834.      Domain: *   P=INT-Co;  A=RDnet; C=CH;
  835.      Domain: =      P=WHY;  A=RDnet; C=CH;
  836.      Domain: *  P=Net Lab; A=Pub400; C=CH;
  837.      #
  838.      RELAY: P=INT-Co; A=RDnet; C=CH; MTAname=mta.one; 10
  839.      RELAY: P=Nat Sa; A=RDnet; C=CH; MTAname=bck-relay.ch; 60
  840.  
  841.    RELAY document 1 (part):
  842.   
  843.      Community: MY-MHS
  844.      #
  845.      RELAY: P=INT-Co; A=RDnet; C=CH; MTAname=mta.one
  846.      #
  847.      Status:              primary
  848.      Password:            none
  849.      RTS-dialog-mode:     TWA
  850.      RTS-checkpoint-size: 10
  851.      RTS-window-size:     19
  852.      #
  853.      Called-address:  Public-X.25/X.25/TP0;
  854.                       Int-X25(80)=22225971014110; MTS-TP-84; 30
  855.      Calling-address: Public-X.25/X.25/TP0;
  856.                       Int-X25(80)=22225971014
  857.      #
  858.      Called-address:  Internet/TCP/RFC1006;
  859.                       Internet-RFC-1006=140.105.1.1; MTS-TP-84; 10
  860.      Calling-address: Internet/TCP/RFC1006;
  861.                       Internet-RFC-1006=140.105.1.1
  862.      #
  863.      System: HW=DEC VAX3100; OS=VMS 5.5; SW=EAN V2.2+
  864.      LocalDomain: O=LocDpt; P=INT-Co; A=RDnet; C=CH;
  865.      #
  866.  
  867.    RELAY document 2 (part):
  868.   
  869.      Community: MY-MHS
  870.      #
  871.      RELAY: P=Nat Sa; A=RDnet; C=CH; MTAname=bck-relay.ch
  872.      #
  873.      Status:          secondary
  874.      Password:        value="call-me"
  875.      RTS-dialog-mode: MONOLOGUE
  876.      #
  877.      Called-address:  EMPB-X25/X.25/TP0;
  878.                       Int-X25(80)=20432240004110; MTS-TP-84
  879.      Calling-address: EMPB-X25/X.25/TP0;
  880.                       Int-X25(80)=20432240004
  881.      #
  882.  
  883.  
  884. Allocchio et. al.      (Doc. expiration date:  June 1993)      [Page 15]
  885.  
  886. I-d v4.1      Internet DNS for X.400 MHS routing data      February 1993
  887.  
  888.  
  889.      Called-address:  Int-CLNS/CLNS/TP4;
  890.                       "88"/NS+39756f11112222223333aa00040005e100; MTS-TP
  891.      Calling-address: Int-CLNS/CLNS/TP4;
  892.                       "88"/NS+39756f11112222223333aa00040005e100
  893.      #
  894.      System: HW=Sun 3; OS=SunOS 5-2; SW=PP 6.0
  895.      LocalDomain: O=managment; P=Nat Sa; A=RDnet; C=CH; 
  896.      #
  897.  
  898.    The routing information contained in the above DOMAIN document will 
  899.    result into 3 couples of MX record, 2 couples with a wildcard 
  900.    specification and one couple with exact matching only.
  901.  
  902.     ;
  903.     ; Domain: * P=INT-Co;  A=RDnet; C=CH;  ---------------------------
  904.     ;
  905.     *.P-INT-h-Co.A-RDnet.C-CH.X400.ARPA.   IN MX 10 \
  906.                                            XX0-P30.IT6-P10.\
  907.     MTA-mta-d-one.O-LocDpt.P-INT-h-Co.A-RDnet.C-CH.X400.ARPA.
  908.     ;
  909.     *.P-INT-h-Co.A-RDnet.C-CH.X400.ARPA.   IN MX 60 \
  910.                                            RX0.LL4.\
  911.     MTA-bck-h-relay-d-ch.O-managment.P-Nat-b-Sa.A-RDnet.C-CH.X400.ARPA.
  912.     ;
  913.     ; Domain: = P=WHY;  A=RDnet; C=CH;  ------------------------------
  914.     ;
  915.     P-WHY.A-RDnet.C-CH.X400.ARPA.          IN MX 10 \
  916.                                            XX0-P30.IT6-P10.\
  917.     MTA-mta-d-one.O-LocDpt.P-INT-h-Co.A-RDnet.C-CH.X400.ARPA.
  918.     ;
  919.     P-WHY.A-RDnet.C-CH.X400.ARPA.          IN MX 60 \
  920.                                            RX0.LL4.\
  921.     MTA-bck-h-relay-d-ch.O-managment.P-Nat-b-Sa.A-RDnet.C-CH.X400.ARPA.
  922.     ;
  923.     ; Domain: * P=Net Lab; A=Pub400; C=CH;  --------------------------
  924.     ;
  925.     *.P-Net-b-Lab.A-Pub400.C-CH.X400.ARPA. IN MX 10 \
  926.                                            XX0-P30.IT6-P10.\
  927.     MTA-mta-d-one.O-LocDpt.P-INT-h-Co.A-RDnet.C-CH.X400.ARPA.
  928.     ;
  929.     *.P-Net-b-Lab.A-Pub400.C-CH.X400.ARPA. IN MX 60 \
  930.                                            RX0.LL4.\
  931.     MTA-bck-h-relay-d-ch.O-managment.P-Nat-b-Sa.A-RDnet.C-CH.X400.ARPA.
  932.     ;
  933.  
  934.    The above records just specify the available relays and connection 
  935.    stacks, but does not yet contain the needed data to establish MTA to 
  936.    MTA links. These data are stored into the below HINFO resource 
  937.    records.
  938.  
  939.  
  940.  
  941.  
  942.  
  943. Allocchio et. al.      (Doc. expiration date:  June 1993)      [Page 16]
  944.  
  945. I-d v4.1      Internet DNS for X.400 MHS routing data      February 1993
  946.  
  947.  
  948.     ;
  949.     ; RELAY: P=INT-Co; A=RDnet; C=CH; MTAname=mta.one ----------------
  950.     ;
  951.     MTA-mta-d-one.O-LocDpt.P-INT-h-Co.A-RDnet.C-CH.X400.ARPA. IN HINFO \
  952.     "primary none TC10W19 HW=DEC VAX3100; OS=VMS 5.5; SW=EAN V2.2+" \
  953.     "XX0.IT6"
  954.     ;
  955.     C.XX0.MTA-mta-d-one.O-LocDpt.P-INT-h-Co.A-RDnet.C-CH.X400.ARPA. \
  956.     IN HINFO "none TC10W19 MTS-TP-84" "Int-X25(80)=22225971014110"
  957.     R.XX0.MTA-mta-d-one.O-LocDpt.P-INT-h-Co.A-RDnet.C-CH.X400.ARPA. \
  958.     IN HINFO "none TC10W19" "Int-X25(80)=22225971014"
  959.     ;
  960.     C.IT6.MTA-mta-d-one.O-LocDpt.P-INT-h-Co.A-RDnet.C-CH.X400.ARPA. \
  961.       IN HINFO "none TC10W19 MTS-TP-84" "Internet-RFC-1006=140.105.1.1"
  962.     R.IT6.MTA-mta-d-one.O-LocDpt.P-INT-h-Co.A-RDnet.C-CH.X400.ARPA. \
  963.       IN HINFO "none TC10W19" "Internet-RFC-1006=140.105.1.1"
  964.     ;
  965.     ; RELAY: P=Nat Sa; A=RDnet; C=CH; MTAname=bck-relay.ch ------------
  966.     ;
  967.     MTA-bck-h-relay-d-ch.O-managment.P-Nat-b-Sa.A-RDnet.C-CH.X400.ARPA.\
  968.      IN HINFO \
  969.      "secondary value=\"call-me\" M HW=Sun 3; OS=SunOS 5-2; SW=PP 6.0" \
  970.      "RX0.LL4"
  971.     ;
  972.     C.RX0.MTA-bck-h-relay-d-ch.O-managment.P-Nat-b-Sa.A-RDnet.C-CH.\
  973.      X400.ARPA. IN HINFO "value=\"call-me\" M MTS-TP-84" \
  974.      "Int-X25(80)=20432240004110"
  975.     R.RX0.MTA-bck-h-relay-d-ch.O-managment.P-Nat-b-Sa.A-RDnet.C-CH.\
  976.      X400.ARPA. IN HINFO "value=\"call-me\" M" "Int-X25(80)=20432240004"
  977.    ;
  978.     C.LL4.MTA-bck-h-relay-d-ch.O-managment.P-Nat-b-Sa.A-RDnet.C-CH.\
  979.      X400.ARPA. IN HINFO "value=\"call-me\" M MTS-TP" 
  980.      "\"88\"/NS+39756f11112222223333aa00040005e100"
  981.     R.LL4.MTA-bck-h-relay-d-ch.O-managment.P-Nat-b-Sa.A-RDnet.C-CH.\
  982.      X400.ARPA. IN HINFO "value=\"call-me\" M"
  983.      "\"88\"/NS+39756f11112222223333aa00040005e100"
  984.  
  985.    Note that the above lines have been wrapped for clarity reasons, 
  986.    using "\" to show continuation on the same line. Only inside the 
  987.    HINFO value the "\" is used to quote the " character and is actual 
  988.    part of the syntax.
  989.  
  990. 4.5 An example of query to DNS for routing data
  991.  
  992.    In this example we will assume that the routing data those defined 
  993.    in section 4.4; let's see how it works.
  994.  
  995.       OR address:   C=ch;A=RDnet;P=Int-Co;O=mgt;S=helpdesk;
  996.  
  997.    After translation of the routing part of the OR address in DNS 
  998.  
  999.  
  1000.  
  1001.  
  1002. Allocchio et. al.      (Doc. expiration date:  June 1993)      [Page 17]
  1003.  
  1004. I-d v4.1      Internet DNS for X.400 MHS routing data      February 1993
  1005.  
  1006.  
  1007.    syntax, a first query for an MX records list will be issued for
  1008.  
  1009.       O-mgt.PRMD-Int-h-Co.ADMD-RDnet.C-ch.X400.ARPA.
  1010.  
  1011.    DNS will match the query with the first couple of MX records listed 
  1012.    in our above example, i.e.
  1013.  
  1014.    IN MX 10 XX0-P30.IT6-P10.MTA-mta-d-one.O-LocDpt.P-INT-h-Co.A-RDnet.\
  1015.             C-CH.X400.ARPA.
  1016.    IN MX 60 RX0.LL4.MTA-bck-h-relay-d-ch.O-managment.P-Nat-b-Sa.\
  1017.             A-RDnet.C-CH.X400.ARPA.
  1018.  
  1019.    The answer contains already a choice between 2 possible RELAYs and 
  1020.    again 2 available connection stacks per each RELAY, identified by 
  1021.    XX0, IT6, RX0 and LL4 keywords and with different priorities. Note 
  1022.    that the <DNS-service-key> contained in each MX record is meaningful
  1023.    and must be unique only within a <DNS-RELAYkey>. 
  1024.  
  1025.    As priority 10 indicated the preferred RELAY, and we already have 
  1026.    also the preferred connection stack (identified by IT6 key, service
  1027.    priority 10) we can query directly for connection data, looking for 
  1028.    an HINFO record like:
  1029.  
  1030.    C.IT6.MTA-mta-d-one.O-LocDpt.P-INT-h-Co.A-RDnet.C-CH.X400.ARPA.
  1031.  
  1032.    and attempt connection to the remote RELAY. If this fails, according 
  1033.    to [EPPEN V3] document, we will then query for the next supported 
  1034.    stack connection record (identified by XX0 key with priority 30 and 
  1035.    by the same <DNS-RELAYkey>). If also this connection fails we will 
  1036.    eventually use the other available RELAY, and continue like that.
  1037.  
  1038.    On the other hand we can also query information about a specific 
  1039.    RELAY starting from the <DNS-RELAYkey>:
  1040.  
  1041.      MTA-mta-d-one.O-LocDpt.P-INT-h-Co.A-RDnet.C-CH.X400.ARPA.
  1042.  
  1043.    It is thus possible to reconstruct the RELAY table data starting 
  1044.    from DNS.
  1045.  
  1046. 5.  Administration of routing information
  1047.  
  1048.    Not all MTAs will be able to use the Internet  DNS  to  obtain the 
  1049.    X.400 routing information. It is in fact expected that MTAs in a 
  1050.    particular country or management domain will conform to one of the 
  1051.    following models:
  1052.  
  1053.              Table-based      DNS-based      X.500-based
  1054.  
  1055.    Table-based countries and management domains will submit and receive 
  1056.    their routing documents from the International MHS coordinator. DNS
  1057.  
  1058.  
  1059.  
  1060.  
  1061. Allocchio et. al.      (Doc. expiration date:  June 1993)      [Page 18]
  1062.  
  1063. I-d v4.1      Internet DNS for X.400 MHS routing data      February 1993
  1064.  
  1065.  
  1066.    based countries and management domains will store their routing 
  1067.    information in the DNS. The DNS Routing coordinator will be 
  1068.    responsible for operating authoritative nameservers for resource  
  1069.    records pertinent to management domains in Table-based communities. 
  1070.    Also, the DNS Routing coordinator will be responsible for generating  
  1071.    the table form of routing data based in the DNS and transmitting it
  1072.    to the International Routing Table coordinator. X.500 based storage 
  1073.    is not yet fully defined.
  1074.  
  1075.    As of this writing, the  International  Routing  Table coordinator is 
  1076.    the COSINE MHS Project Team and the DNS Routing coordinator is the 
  1077.    COSINE Gateway Service.
  1078.  
  1079.    A set of coordination procedures to keep aligned the three routing 
  1080.    distribution services will be published in the implementation phase 
  1081.    document.
  1082.  
  1083. 6. Conclusion
  1084.  
  1085.    The use of the MX and HINFO resource-records and a new name space 
  1086.    tree promise to provide a good possible repository for X.400 MHS 
  1087.    routing information. The information is stored in the DNS tree 
  1088.    structure so that it can be easily obtained using the DNS distributed
  1089.    name-service. 
  1090.    At the same time the introduction of the new "X400.ARPA" domain name 
  1091.    space allows us also to use the DNS to store and distribute many 
  1092.    other X.400 MHS information, including the mapping ones. The use of 
  1093.    the DNS has many advantages in storing, managing and updating 
  1094.    information. Using the existing resource records in the new name 
  1095.    tree does not even require the introduction of new types. A 
  1096.    successful number of tests have been performed under the provisional
  1097.    top level domain "X400.IT", and their results confirmed the 
  1098.    advantages of the method.
  1099.  
  1100.    Software to query the DNS and then to convert between the textual 
  1101.    representation of DNS resource records and the address format defined 
  1102.    in [EPPEN V3] needs to be developed.  Also some tools to derive DNS 
  1103.    format from DOMAIN and RELAY documents will be needed to help the 
  1104.    implementation of this specification.
  1105.  
  1106. 7.  References
  1107.  
  1108.    [CCITT]    CCITT SG 5/VII, "Recommendation X.400," Message Handling 
  1109.               Systems: System Model - Service Elements, October 1988.
  1110.  
  1111.    [RFC 1327] Kille, S., "Mapping between X.400(1988)/ISO 10021 and 
  1112.               RFC 822", RFC 1327, March 1992
  1113.  
  1114.    [RFC 1034] Mockapetris, P., "Domain Names - Concepts and Facilities",
  1115.               RFC 1034, USC/Information Sciences Institute, February 
  1116.               1987.
  1117.  
  1118.  
  1119.  
  1120. Allocchio et. al.      (Doc. expiration date:  June 1993)      [Page 19]
  1121.  
  1122. I-d v4.1      Internet DNS for X.400 MHS routing data      February 1993
  1123.  
  1124.  
  1125.    [RFC 1035] Mockapetris, P., "Domain names - Implementation and  
  1126.               Specification", RFC 1035, USC/Information Sciences 
  1127.               Institute, November 1987.
  1128.  
  1129.    [EPPEN V3] Eppenberger, U., "Routing coordination for X.400 MHS
  1130.               services within a multi protocol / multi network
  1131.               environment - Table Format V3 for static routing",
  1132.               Internet-Draft, COSINE-MHS/SWITCH, February 1993.
  1133.  
  1134. 8. Authors addresses:
  1135.  
  1136.     Claudio Allocchio      RFC822: Claudio.Allocchio@elettra.trieste.it
  1137.     Sincrotrone Trieste    X.400:  C=it;A=garr;P=infn;OU=elettra-ts;
  1138.     c/o Area di Ricerca            S=Allocchio;G=Claudio;
  1139.     Padriciano 99          Phone:  +39 40 3758523
  1140.     I 34012 Trieste        Fax:    +39 40 226338
  1141.     Italy
  1142.  
  1143.     Antonio Blasco Bonito  RFC822: bonito@cnuce.cnr.it
  1144.     CNUCE - CNR            X.400:  C=it;A=garr;P=cnr;O=cnuce;S=bonito;
  1145.     Reparto infr. reti     Phone:  +39 50 593246
  1146.     Viale S. Maria 36      Fax:    +39 50 589354
  1147.     I 56126 Pisa
  1148.     Italy
  1149.  
  1150.     Bruce Cole             RFC822: bcole@cisco.com
  1151.     Cisco Systems Inc.     X.400:  C=us;A= ;P=Internet;
  1152.     P.O. Box 3075                  DD.rfc-822=bcole(a)cisco.com;
  1153.     1525 O'Brien Drive     Phone:  +1 415 6888245
  1154.     Menlo Park, CA 94026   Fax:    +1 415 6884575
  1155.     U.S.A.
  1156.  
  1157.     Silvia Giordano        RFC822: giordano@cscs.ch
  1158.     Centro Svizzero di     X.400:  C=ch;A=arcom;P=switch;O=cscs;
  1159.     Calcolo Scientifico            S=giordano;
  1160.     Via Cantonale          Phone:  +41 91 508213
  1161.     CH 6928 Manno          Fax:    +41 91 506711
  1162.     Switzerland
  1163.  
  1164.     Robert Hagens          RFC822: hagens@ans.net
  1165.     Advanced Network       X.400:  C=us;A= ;P=Internet;
  1166.     and Services                   DD.rfc-822=hagens(a)ans.net;
  1167.     1875 Campus Commons    Phone:  +1 703 7587700
  1168.     Drive
  1169.     Reston, VA 22091
  1170.     U.S.A.
  1171.  
  1172.  
  1173.  
  1174.  
  1175.  
  1176.  
  1177.  
  1178.  
  1179. Allocchio et. al.      (Doc. expiration date:  June 1993)      [Page 20]
  1180.